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A first cipher stream generated 
(120) from a private key negotiated as 
a result of a public key exchange is 
partitioned (121) to form a sequence 
of secondary keys. The secondary keys 
are then indexed. In one instance, each 
plain text data packet is encrypted with 
a second cipher stream (123) generated 
from a different one of the secondary 
keys. In another instance, a second cipher 
stream generated from a single secondary 
key is used to encrypt a plurality of 
plaintext data packets. A new second 
cipher stream generated from another 
one of the secondary keys is then used 
for encryption following each instance 
of the loss of a ciphertext data packet. 
The index is communicated with the 
ciphertext to identify which secondary 
key is to be used in generating the second 
cipher stream needed for decryption. 
With knowledge of the secondary key 
to be used, re-synchronization (along 
with new private key negotiation) at each 
instance of a ciphertext data packet loss 
is obviated. 
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ENCRYPTION OF DATA PACKETS USING A 
SEQUENCE OF PRIVATE KEYS 
GENERATED FROM A PUBLIC KEY EXCHANGE 

BACKGROUND OF THE INVENTION 
Technical Field of the Invention 

The present* invention relates to communications and, in particular, to 
encrypting communications for transmission over unsecured communications channels 
5 using public key/private key techniques. 
Description of Related Art 

Communications take place over many different types of channel media such 
as wireline, radio frequency, fiber optic, and the like. The communications carried 
over each of these media are, however, subject to interception (commonly referred to 

o 

10 as "eavesdropping"). In instances where a communication concerns sensitive or 
proprietary information, it is common for the parties to the communication to employ 
a security protocol (such as encryption or scrambling) in order to prevent the 
eavesdropper from being able to discover the communicated information. 

In encryption, a plaintext message is encrypted by a sender into a ciphertext 

15 message using a key (cryptovariable) and then sent over a communications channel. 
A receiver then decQrpts the communications channel transmitted ciphertext message 
using the same key. An eavesdropper, who presumably does not have access to the 
key, cannot decrypt the transmitted ciphertext message to recover the plaintext 
message. Any sensitive or proprietary information contained within the plaintext 

2 0 message is thus safely communicated. 

It is not unusual for the sender and receiver to be located at a considerable 
distance from each other. In such cases, a number of problems arise in ensuring that 
the designated key rfecessary for decryption is securely communicated to the receiver. 
A secure channel, such as a courier service, may be used to communicate the key. 

2 5 However, such channels tend to be expensive, slow, and perhaps even unsecured in 

instances where the trustworthiness of the courier is compromised. 

To address this problem of key distribution, public key methods have been 
developed for security protocols wherein a sender and receiver may independently 
determine a common secret key by exchanging information based on secret parameters 

3 0 known only to them. The information that is exchanged is known as "public keys", 

and although subject to intervention the common secret key cannot be determined by 
the eavesdropper without having access to the secret parameters. One such well 
known public key encryption scheme is the Diffie-Hellman algorithm. See, U.S. 
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Patent No. 4,200,770, to Hellman, et al. and U.S. Patent No. 4,218,582, to Hellman, 
etal. 

Reference is now made to FIGURES 1 and 2 wherein FIGURE 1 is a block 
diagram of a secure communications system 10 in accordance with the prior art which 
implements the Diffie-Hellman public key encryption technique, and FIGURE 2 is a 
signal flow diagram illustrating prior art key exchange, encrypted data communication, 
and re-synchronization processes. There are two parties, Party A and Party B, to a 
conversation which is being carried over an unsecured communications channel 11 
supported by, for example, a wireline, radio frequency, fiber optic, or the like, 
communications link. Each party has access to a security device 12 positioned at 
opposite ends of the communications channel 11. Each security device includes a 
random number generator 14, a key generator 16 and an encryption/decryption device 
18 (implementing a stream cipher such as RC4). The encrypting/decrypting device 18 
comprises a cipher stream generator 20 and an exclusive OR (XOR) multiplier 22. 

A data communication (perhaps comprising digitized speech or data in the 
form of data packets) referred to as plaintext (PT) is being earned between Party A and 
Party B on lines 24 and over the channel 1 1 . At this point in time, plaintext is being 
passed directly (i.e., without encryption) through the encrypting/decrypting device 18. 
It is then decided to encrypt the communication. The random number generator 14 of 
the security device 12A for Party A produces a secret random quantity y. Key 
generator 16 then generates two public quantities: 

a, referred to as a base vector, which is an integer; and 
p, referred to as a modulus, which is a prime number larger than a. 
From these public quantities and the secret random quantity, the key generator 1 6 for 
Party A generates a public key PK A in accordance with the following: 

PK = a y mod p (D 

A 

The security device 12A then initiates a key exchange with the security device 12B for 
Party B. A triplet (a,p,PK A ) is sent by the security device 12A to the security device 
12B over the communications channel 1 1 in a key exchange message (IKE). It will 
be understood that to the extent a and p are previously agreed upon by Party A and 
Party B, they do. not need to be included in the key exchange message. It will be noted 
here that the key exchange message is being sent without encryption. However, this 
is of no concern as the function for computing PK A is a one-way function (i.e., it is 
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mathematically impossible for an eavesdropper to determine the secret random 
quantity y from knowledge of PK A ). 

In response to the key exchange message, the security device 12B for Party B 
has its random number generator 14 produce a secret random quantity x. Key 
generator 16 then generates for Party B a public key PK B in accordance with the 
following: 



PK = a * mod p (2) 



B 



The security device 12B then completes the key exchange with the security device 
12A for Party A. The public key (PK B ) is sent by the security device 12B to the 
security device 12A over the communications channel 1 1 in a key exchange response 
10 message (EKE). It will be noted again that the key exchange response message is 
being sent without encryption. Again, this is of no concern as the function for 
computing PK B is a one-way function, and thus the eavesdropper cannot utilize 
mathematical processing to determine the secret random quantity x from knowledge 
of PK B . 

15 The key generators 16 of the security devices 12 for Party A and Party B now 

independently generate a shared private key K in accordance with the following: 

K = a xy mod p ^ 3 ) 

The key generator 16 for the Party A security device 12A generates K as follows: 

K = a xy mod p = PK B a y mod p (4) 

o 

Similarly, the key generator 16 for the Party B security device 12B generates K as 
follows: 

K = a xy mod p = PK A a x mod p (5) 

2 0 While the security devices 1 2A and 12B are able to independently generate the same 
secret key K, it will be recognized that an eavesdropper is unable to compute the 



o 
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private key, in spite of having access to the public keys PK A and PK B , because 
knowledge of the necessary secret random quantities x and y is unknown and cannot 
be mathematically determined. The private keys K are then applied to initialize the 
cipher stream generators 20 which output a cipher stream C that is either exclusively 
ORed 22 with the plaintext (PT) to generate ciphertext (CT) for transmission over the 
channel 11, or exclusively ORed with received ciphertext to generate the original 
plaintext. 

For a bi-directional data communication between Party A and Party B as 
illustrated in FIGURE 1, the secret key K actually comprises (i.e., may be split into) 
two keys K AB and K BA . The first private key is used by security device 12A to 
generate a cipher stream for encrypting Party A data communications, and by security 
device 12B to generate a cipher stream for decrypting Party A data communications. 
Conversely, the second private key K BA is used by security device 12B to generate a 
cipher stream for encrypting Party B data communications, and by security device 1 2 A 
to generate a cipher stream for decrypting Party B data communications. The need for 
two private keys when handling bi-directional communications is required to ensure 
that the same generated cipher stream is never used for the encryption of different 

plaintext sequences. 

Once the cipher stream generators 20 are initialized with the appropriate 
private key K, they must remain synchronized in order to ensure proper conversion 
between plaintext and ciphertext. The communications channel accordingly must be 
able to guarantee an ordered (i.e., correctly sequenced) delivery of any encrypted 
sequenced data packets so that synchronization may be maintained. In the event 
synchronization is lost, for example due to a loss of an encrypted data packet during 
transmission over the channel 11, re-synchronization followed by encryption with a 
new private key must occur. This is so because the recovery of plaintext is easily 
accomplished with knowledge of two different plaintext messages encrypted with the 
same cipher stream C (i.e., produced from the same private key K). 

Re-synchronization then requires a new exchange of public keys, followed by 
the independent generation of another private key and appropriate initialization of the 
cipher stream generators 20. This process is undesirable as it significantly delays 
completion of the data communication and consumes valuable communications 
resources (i.e., wastes bandwidth) on the channel 11 during the key exchange that 
could otherwise be used in carrying communications which generate revenue. 
Furthermore, if one of the parties to the communication comprises a mobile 
communications device (such as a cellular telephone) the computation of the private 
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key is a processor intensive operation requiring a significant time expenditure and 
causing a significant drain on battery power resources. 

The incidence of encrypted data packet loss necessitating re-synchronization 
is especially high°in connection with those communications channels 11, such as 
wireless radio frequency communications channels, which suffer from interference, 
distortion or fading. In fact, a five to ten percent data packet loss rate in connection 
with the use of wireless communications channels is not uncommon. Each instance 
of packet loss in connection with encrypted sensitive or proprietary information data 
communications then unfortunately necessitates an inefficient re-synchronization. For 
sensitive or proprietary information data communications carried over such 
communications channels, there is a need then for a more efficient and effective 
security protocol which does not necessarily require re-synchronization in the event 
of a data packet loss. 

SUMMARY OF THE INVENTION 

To obviate the need for re-synchronization following loss of a ciphertext data 
packet, the present invention partitions a private key generated cipher stream into an 
indexed sequence of secondary keys. The secondary keys are then utilized on a 
selective basis to encrypt plaintext data packets for transmission over a 
communications channel. Each transmitted ciphertext data packet then includes an 
index identifying which of the plurality of secondary keys was used for the encryption. 
In one embodiment, each plaintext data packet is encrypted by a cipher stream 
generated from a different one of the secondary keys. In another embodiment, the a 
cipher stream generated from a single secondary key is utilized to encrypt plaintext 
data packets until loss of a ciphertext data packet occurs. At that point, a cipher stream 
generated from a next one of the plurality of secondary keys is used for encryption. 
In each case, however, no re-synchronization need occur as the index included with 
each ciphertext data packet identifies the secondary key to be used for decryption. 

BRIEF DESCRIPTION OF THE DRAWINGS 

A more complete understanding of the method and apparatus of the present 
invention may be acquired by reference to the following Detailed Description when 
taken in conjunction with the accompanying Drawings wherein: 

FIGURE 1 (previously described) is a block diagram of a secure 
communications system in accordance with the prior art which implements the Diffie- 
Hellman public key encryption technique; 
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FIGURE 2|previously described) is a signal flow diagram illustrating prior art 
key exchange, encrypted data communication, and re-synchronization processes; 

FIGURE 3 is a block diagram of a secure communications system in 
accordance with the present invention; 

FIGURE 4 is a flow diagram for secondary private key generation; 

FIGURE 5 is a simplified format used for the transmission of an encrypted data 
communication ^accordance with the present invention; 

FIGURE 6 is a diagram illustrating a page organization of the sequence of 

secondary private keys; 

FIGURE 7 is a signal flow diagram illustrating the key exchange, encrypted 
data communication, and re-synchronization processes of the present invention; 

FIGURE 8 is a state control diagram illustrating an encryption key 
management process of the present invention; and 

FIGURE 9 is a signal flow diagram illustrating the key exchange, encrypted 
data communication, and re-synchronization processes of an alternative embodiment 
for the present invention. 



DETAILED DESCRIPTION OF THE DRAWINGS 

Reference is now made to FIGURE 3 wherein there is shown a block diagram 
of a secure communications system 100 in accordance with the present invention. 
There are two parties, Party A and Party B, to a conversation which is being carried 
over an unsecured communications channel 1 1 1 supported by, for example, a wireline, 
radio frequency, fiber optic, or the like, communications link. Each party has access 
to a security device 112 positioned at opposite ends of the communications channel 
111. Each security device includes a random number generator 1 1 4, a key generator 
116 and an encrypting/decrypting device 118 (implementing any suitable stream 
cipher including,cfor example, RC4). The encrypting/decrypting device 1 1 8 comprises 
a first cipher stream generator 120, a partitioning and indexing device 121, a second 
cipher stream generator 123 and an exclusive OR (XOR) multiplier 122. 

A data communication (perhaps comprising digitized speech or data in the 
form of data packets) referred to as plaintext (PT) is being carried between Party A and 
Party B on lines 1 24 and over the channel 111. At this point in time, plaintext is being 
passed directly (i.e., without encryption) through the encrypting/decrypting device 
118. A decision is then made to switch to encrypted communication. The selection 
of a common secret key for encrypting Party A and Party B communications may be 
made using any suitable public key exchange method including, for example, the 
Diffie-Hellman method. The random number generator 114 of the security device 
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1 1 2A for Party A produces a random quantity y . Key generator 1 1 6 then generates the 
two public quantities a and p. From these public quantities and the secret random 
quantity, the key generator 1 14 for Party A generates a public key PK A in accordance 
with Equation (1). The security device 1 12A then initiates a key exchange with the 
5 security device 1 12B for Party B. A triplet (a,p,PK A ) is sent by the security device 
112A to the security device 112B over the communications channel 111 in a key 
exchange message (IKE). It will be understood that to the extent a and p are 
previously agreed upon by Parry A and Party B, they do not need to be included in the 
key exchange message. It will be remembered that the key exchange message is being 
1 o sent without encryption. However, this is of no concern as the function for computing 
PK A is a one-way function (i.e., it is mathematically impossible for an eavesdropper 
to determine the secret random quantity y from knowledge of PK A ). 

In response to the key exchange message, the security device 1 1 2B for Party 
B has its random number generator 1 14 produce a random quantity x. Key generator 
15 1 1 6 then generates for Party B a public key PK B in accordance with Equation (2). The 
security device 1 12B then completes the key exchange with the security device 1 12A 
for Party A. The public key (PK B ) is sent by the security device 1 12B to the security 
device 112A over the communications channel 111 in a key exchange response 
message (EKE). It will be remembered that the key exchange response message is 
20 being sent without encryption. Again, this is of no concern as the function for 
computing PK B is a one-way function, and thus the eavesdropper cannot utilize 
mathematical processing to determine the secret random quantity x from knowledge 
of PK B . 

The key generators 116 of the security devices 112 for Party A and Party B 
2 5 now independently generate a shared private key K in accordance with Equations (4) 
and (5), respectively. While the security devices 112A and 112B are able to 
independently generate the same private key K, it will be recognized that an 
eavesdropper is unable to compute the private key, in spite of having access to the 
public keys PK A and PK B , because knowledge of the secret random quantities x and 
y is unknown and cannot be mathematically determined. The private keys K are then 
applied to initialize the first cipher stream generators 120 which output a first cipher 
stream C. 

This first cipher stream C is then processed by the partition and index device 
121 which partitions the cipher stream into a sequence of secondary private keys 
C„C 2 ,...,Ci. The sequence of secondary private keys C„C 2 ,...,Cj is then applied to 
initialize the second cipher stream generators 123 which output a second cipher stream 
C. This second cipher stream C is then either exclusively ORed 122 with the 
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plaintext sequence (PTj) to generate ciphertext (CTj) for transmission over the channel 
111, or exclusively ORed with received ciphertext to generate plaintext. Each 
secondary private key Q is further provisioned by the device 121 with a uniquely 
identifying index. The index indicating which secondary private key C 4 is being used 
to encrypt a particular plaintext sequence PTj is communicated over the channel 1 1 1 
to ensure synchronization and the utilization of the correct key for decryption. This 
index may be exchanged between the security devices 112 in un-encrypted form 
because it bears no information concerning the secondary private key Q other than a 
sequence (i.e., indexing) number. 

Reference is now made to FIGURE 4 wherein there is shown a flow diagram 
for secondary private key generation. For a bi-directional data communication 
between Party A and Party B as illustrated in FIGURE 3,lhe private key K actually 
comprises (i.e., may be split into) two keys K AB and K BA . The need for two private 
keys when handling bi-directional communications is required to ensure that the same 
cipher stream is never used for the encryption of different plaintext sequences. The 
first private key is used to generate a forward first cipher stream C AB , and the 
second private key K BA is used to generate a reverse first cipher stream C BA . The 
forward first cipher stream is then partitioned and indexed to generate a first (or 
forward channel) secondary private key sequence, with individual ones in the 
sequence used to generate a forward second cipher stream C^' that is used by security 
device 112A to encrypt Party A PT { data communications, and by security device 
1 12B to decrypt Party A CT { data communications. The reverse first cipher stream 
C BA , on the other hand, is then partitioned and indexed to generate a second (or reverse 
channel) secondary private key C BAi sequence, with individual ones in the sequence 
used to generate a reverse second cipher stream C BA ' that is used by security device 
1 12B to encrypt Party B PTj data communications, and by security device 1 12 A to 
decrypt Party B CTj data communications. 

References now made to FIGURE 5 wherein there is shown a simplified 
format 140 used for the transmission of an encrypted data communication segment 
(CTj) 142 in accordance with the present invention. The format 140 includes a 
plurality of fields (OTHER) 144 relating, for example, to packet reconstruction, 
compression and network layer protocol, which are not relevant to the present 
invention. The format further includes a primary key index field (PKI) 146 which 
indicates the parity of the primary encryption/decryption key K used to generate the 
plurality of secondary keys Q. A secondary key index field 148, comprising a page 
identification 150 and a location (on the page) identification 152, is also included in 
the format 140. As noted above, a sequence of secondary private keys C,,^ -A is 
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generated. The i generated keys are arranged in n groups (or pages) of m keys each. 
The page identification 152 accordingly identifies which of the n groups of keys is 
being used to encrypt the data. The location identification 152 then identifies which 
particular one of the m keys on the identified page n is being used to encrypt the data. 
This page organization of the sequence of secondary private keys C l3 C 3 ...,C js 
illustrated in FIGURE 6. 

Reference is now made to FIGURE 7 wherein there is shown a signal flow 
diagram illustrating the key exchange, encrypted data communication, and re- 
synchronization processes of the present invention. Party A and Party B are engaged 
in a plaintext communication 170. The public key exchange process is then initiated 
with Party A generation of the secret quantity y (action 172) and the public key PK A 
(action 174). The key exchange message (IKE) 176 is then sent to Party B. Party B 
responds by generating secret quantity x (action 178) and the public key PK B (action 
180). The key exchange response message (EKE) 1 82 is then sent to Party A. Party 
A and Party B then independently generate (action 184) the private key K from which 
the sequence of secondary private keys C,,^,...^ is generated (action 186). 

In order to simplify the illustration, only the encryption of data 
communications 188 transmitted from Party A to Party B is shown. A first plaintext 
sequence PT t is then encrypted using a second cipher stream C generated from the 
first one of the secondary private keys C, to produce a first ciphertext sequence CIV 
A similar process is used to produce a second ciphertext sequence CT 2 from a second 
cipher stream C* generated from the second one of the secondary private keys C 2 . This 
process continues for each of the subsequent plaintext sequences PT^ 

It is noted, however, that with respect to the j-th plaintext sequence PT 3 
encrypted with a second cipher stream C* generated from the secondary private key 
Cj, the ciphertext^equence CTj was not successfully transmitted (as indicated by "X"). 
In accordance with the prior art process as illustrated in FIGURE 2, this packet loss 
would require an immediate re-synchronization necessitating a new public key 
exchange and cipher stream initialization. In the present invention, synchronization 
is maintained allowing for continued packet transmission starting with the ciphertext 
sequence CT j+1 encrypted using a second cipher stream C generated from the 
secondary private key C j+1 . The reason synchronization is maintained is that each 
ciphertext sequence CTj is formatted for transmission (FIGURE 5) to include 
information (index 148) identifying which secondary key (page and location) should 
be utilized in generated the second cipher stream C\ needed for decrypting the 
transmission. As plural keys have been negotiated and the current encryption key can 
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be identified, there is no need to negotiate a new key for continuing with the 
communication. 0 

Following the processing of one page of data packets (i.e., the encryption of 
m plaintext sequences PTj with individual second cipher streams C* generated from 
m secondary private keys Q), a key management message 190 is sent from Party A to 
Party B. This message 190 identifies the index m and page n that Party A is using to 
encrypt (and/or decrypt) data communications. Responsive to the message 190, Party 
B sends a key management response message 192 confirming its coordinated use of 
a secondary privatekey from the same page n, and index m therein, for encryption and 
decryption. Encryption in the foregoing manner utilizing a second cipher stream C 
generated from an appropriate next secondary secret key then ensues. Key 
management occurs following the use of a last secondary secret key of a page. 

Then, following the processing of all pages of data packets (i.e., the encryption 
of i plaintext sequences PT i5 the last one being encrypted with a second cipher stream 
C generated from the secondary private key Q), the process re-synchronizes 194 to 
invoke the generation of a new set of secondary private keys (actions 184 and 186). 
Accordingly, secret quantities must be selected (actions 172 and 178), public keys 
generated (actions 174 and 180), and key exchange messages (IKE/EKE) 176 and 182 
sent. 

Reference is now made to FIGURE 8 wherein there is shown a state control 
diagram illustrating an encryption key management process of the present invention. 
In normal operation, the protocol state for key management transitions between a 
utilize current secondary private key state 196 and a generate next secondary private 
key state 198. In state 196, a data packet is either encrypted or decrypted using a 
second cipher stream generated from the current secondary private key. A transition 
is then made, following each encryption/decryption, to state 198 where a next 
secondary private key is generated. A transition is then made back to state 196 where 
this newly generate secondary private key becomes the current one for use in 
generating the second cipher stream needed for encrypting or decrypting a next data 
packet. 

Maintenance of synchronization between Party A and Party B as to the proper 
secondary private key is accomplished through either a passive operation, an active 
secondary key operation, or an active primary key operation. In passive operation, no 
message exchange between Party A and Party B regarding synchronization is required 
as the index is n^erely passively incremented with each encryption or decryption and 
monitoring of the index field 148 (FIGURE 5) of each sent ciphertext sequence CT,. 
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In active secondary key operation, a transition is made from state 198 to a 
confirm secondary index state 200. In the state 198, key management messages 190 
and 192 (FIGURE 7) are exchanged between Party A and Party B confirming 
coordinated use of a secondary private key from the same page n, and index m therein, 
5 for encryption and decryption. Once secondary key confirmation has been received, 
a transition is made back to state 198. With respect to the page organization of 
secondary private keys Q illustrated in FIGURE 6, state 200 is entered into following 
the completed transmission of one page worth of data packets. 

In active primary key operation, a transition is made from state 198 to a key 
.0 exchange state 202. In state 202, a re-synchronization is performed to invoke the 
generation of a new set of secondary private keys (actions 1 84 and 1 86 of FIGURE 7) 
by selecting new secret quantities, generating new public keys generated and sending 
key exchange messages (KE/EKE). With respect to the page organization of 
secondary private keys C { illustrated in FIGURE 6, state 202 is entered into following 
L 5 the completed transmission of all n pages worth of data packets. 

Simplified pseudo code describing state transitions in FIGURE 8 with respect 
to passive secondary key operation may be written as follows: 
IF request for next secondary private key 
THEN increment index 
2 0 IF index <= m 

THEN {use secondary key at incremented index location} 
IF index > m AND page < n 
THEN initiate active secondary key operation 
ELSE {full sequence of secondary private keys Cj used, initiate active 
25 ° primary key operation} 

Simplified pseudo code describing state transitions in FIGURE 8 with respect 
to encrypting side active secondary key operation may be written as follows: 
IF secondary key requested > m 
THEN reset index 
30 IF page<=n 

TfcTRN {send key management message to peer (decrypting entity) 
identifying next page} 
IF peer responds and confirms 

THEN {increment page, use first secondary private key at 
3 5 incremented page location} 

ELSE IF {error regarding key management message} 
THEN repeat procedure 
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ELSE {full sequence of secondary private keys C { and secondary key 
pages used, initiate active primary key operation} 
Simplified pseudo code describing state transitions in FIGURE 8 with respect 
to decrypting side active secondary key operation may be written as follows: 

IF {key management message received from peer (encrypting entity) 

identifies page greater than current page} 
THEN {increment page to match identified page 
respond to key management message 

IF {data packet received with page index set to incremented page} 
THEN {initialize decryption using secondary key indexed from 
incremented page} 

} 

Simplified pseudo code describing state transitions in FIGURE 8 with respect 
to Party A active primary key operation may be written as follows: 
IF new primary keys are required 
THEN construct and send IKE message (plaintext) 

IF {receive EKE message responsive to IKE message} 

THEN {execute public key algorithms, deduce new private key and 

secondary private keys} 
ELSE IF error regarding IKE message 
THEN complete procedure or retransmit IKE 

IF receive an EKE message (response required) 
THEN discard EKE message 
IF receive an EKE message (response required) 
THEN construct and transmit an IKE message (plaintext) 
Simplified pseudo code describing state transitions in FIGURE 8 with respect 
to Party B activecprimary key operation may be written as follows: 
IF new primary keys are required 
THEN construct and send EKE message (plaintext) 
IF receive IKE message 

THEN {execute public key algorithms, deduce new private key and 

secondary private keys} 
IF receive IKE message (response required) 
TfflEN {construct and transmit EKE message (plaintext),execute 

public key algorithms, deduce new private key and secondary 

private keys, advance index} 
ELSE IF error regarding EKE message 



3/27/07, EAST Version: 2.1.0.14 



PCT/SE98/01502 

13- 

THEN complete procedure 
IF receive IKE message (response required) 

THEN {construct and transmit EKE message (plaintext),execute public key 
algorithms, deduce new private key and secondary private keys, 
5 advance index} 

Reference is now once again made to the state control diagram of FIGURE 8 
for a description of an alternative embodiment of the present invention. It will be 
remembered that in connection with the prior description, the protocol state for key 
management transitions between the current secondary private key state 196 and the 
10 generate next secondary private key state 198. The transition from state 196 (data 
packet encryption/decryption using the current secondary private key) to state 198 
(where a next secondary private key is generated) occurs after each such 
encryption/decryption operation on a data packet. In the current embodiment, this 
transition occurs only each time that a data packet delivery fails. Thus, a second 
15 cipher stream C generated from a single secondary private key is used to 
encrypt/decrypt plural data packets. It is only when a packet delivery failure occurs 
that the index is incremented and a new secondary private key is accessed for use. As 
before, maintenance of synchronization between Party A and Party B as to the proper 
secondary private key for use is accomplished through either the passive operation, the 
2 0 active secondary key operation, or the active primary key operation. 

Reference is now made to FIGURE 9 wherein there is shown a signal flow 
diagram illustrating the key exchange, encrypted data communication, and re- 
synchronization processes of an alternate embodiment for the present invention. Party 
A and Party B are engaged in a plaintext communication 170. The public key 
25 exchange process is then initiated with Party A generation of the secret quantity y 
(action 172) and the public key PK A (action 174). The key exchange message (IKE) 
176 is then sent to Party B. Party B responds by generating secret quantity x (action 
1 78) and the public key PK B (action 1 80). The key exchange response message (EKE) 
182 is then sent to Party A. Party A and Party B then independently generate (action 
30 1 84) the private Icey K from which the sequence of secondary private keys C l ,C 2 ,...,C i 
is generated (action 1 86). 

In order to simplify the illustration, only the encryption of data 
communications 1 88' transmitted from Party A to Party B is shown. A first one of the 
secondary private keys C x is used to generate a second cipher stream C for encrypting 
3 5 plural plaintext sequences PT and producing corresponding ciphertext sequences CT. 
The use of the sqpond cipher stream C* generated from a single secondary private key 
C t to encrypt plaintext sequences continues until such time as a delivery failure occurs 
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(as indicated by "X"). At that point, a next one of the secondary private keys C 2 is 
used to generate a new second cipher stream C for encrypting subsequent plural 
plaintext sequences PT and producing corresponding ciphertext sequences CT. Again, 
as in the prior embodiment, the reason synchronization* is maintained in spite of 
5 delivery failure is that each ciphertext sequence CT is formatted for transmission 
(FIGURE 5) to include information (index 148) identifying which secondary key 
should be utilized to generate the second cipher stream C needed for decrypting the 
transmission. As the encryption key can be identified, there is no need to negotiate a 
new key for continuing with the communication. 
10 Following the use one page worth (i.e., minnumber) of secondary private keys 

Cj to generate corresponding second cipher streams C each encrypting a plurality of 
plaintext sequences PT, a key management message 190 is sent from Party A to Party 
B. This message 190 identifies the index m and page n that Party A is using to encrypt 
(and/or decrypt) data communications. Responsive to the message 190, Party B sends 
15 a key management response message 192 confirming its coordinated use of a 
secondary private key from the same page n, and index m therein, for encryption and 
decryption. Encryption in the foregoing manner utilizing a second cipher stream C 
generated from an appropriate next secondary secret key then ensues. Key 
management occibts following the use of a last secondary secret key of a page. Then, 
20 following the use of all pages (i.e., n in number) of secondary private keys C s to 
generate second cipher streams C* for encrypting a plurality of plaintext sequences PT 
(the last sequence of data packets being encrypted with a second cipher stream 
generated from the secondary private key Q), the process re-synchronizes 194 to 
invoke the generation of a new set of secondary private keys (actions 184 and 186). 
25 Accordingly, secret quantities must be selected (actions 172 and 178), public keys 
generated (actions 1 74 and 1 80), and key exchange messages (EKE/EKE) 1 76 and 1 82 
are sent. 

The pseudo code previously provided is equally applicable to this embodiment, 
with minor modification as necessary to account for the operational difference between 
3 0 utilizing a new key with each sequence/packet and using a new key with each delivery 
failure. 

It will ba recognized that this embodiment of the present invention utilizes 
secondary private keys at a much lower rate than the preceding embodiment. Thus, 
key management transactions (190 and 192) as well as re-synchronization actions 
35 (194) occur less frequently, and a more efficient use of limited bandwidth 
communications resources is made. 
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Although preferred embodiments of the method and apparatus of the present 
invention have been illustrated in the accompanying Drawings and described in the 
foregoing Detailed Description, it will be understood that the invention is not limited 
to the embodiments disclosed, but is capable of numerous rearrangements, 
5 modifications and substitutions without departing from the spirit of the invention as 
set forth and defined by the following claims. 
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WHAT IS CLAIMED IS: 

1 . A private key generator, comprising; 
a first generator for generating a private key; 

a second generator initialized with the private key for generating a first cipher 
5 stream, the first cipher stream partitioned into a plurality of secondary keys for use in 
encrypting plaintext information into ciphertext information; and 

an indexer for indexing the plurality of secondary keys, an index included with 
the ciphertext information identifying which of the indexed plurality of secondary keys 
was used in encrypting the plaintext information. 

0 2. The private key generator as in claim 1 further including: 

means for exchanging public keys; and 

wherein the first generator functions to generate the private key from 
processing at least one of the exchanged public keys. 

3. The private key generator as in claim 1 wherein the plaintext 
L 5 information comprises a plurality of plaintext packets, each plaintext packet encrypted 

with a second cipher stream generated from a different one of the secondary keys. 

4. The private key generator as in claim 1 wherein the plaintext 
information comprises a plurality of plaintext packets, each sequence of plaintext 
packets handled between instances of ciphertext information loss encrypted with a 

2 0 second cipher stream generated from a different one of the secondary keys. 

5. The private key generator as in claim 1 wherein the first generator 
generates a new private key when each of the generated plurality of secondary keys 
from a prior private key has been used for encryption. 

6. A method for generating a private key, comprising the steps of: 

2 5 gene ratingji private key; 

generating a first cipher stream in itialized frnrn the generated private kev: 
partitioning the first cipher stream into a plurality of secondary keys for use in 
encrypting plaintext information into ciphertext information; and 

indexing the plurality of" secondary keys, an index included with the ciphertext 

3 o information identifying which of the indexed plurality of secondary keys was used in 

encrypting the plaintext information. 
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7. The method as in claim 6 further including the steps of: 
exchanging public keys; and 

generating the private key from processing at least one of the exchanged public 

keys. 

8. The method as in claim 6 wherein the plaintext information comprises 
a plurality of plaintext packets, further including the steps of: 

generating a plurality of s econd cipher stream s, each second cipher stream 
initialized from a~different one of the secondary keys; and 

encrypting each plaintext packet with a different one of the plurality of second 
cipher streams. 

9. The method as in claim 6 wherein the plaintext information comprises 
a plurality of plaintext packets, further including the steps of: 

generating a plurality of second cipher streams, each second cipher stream 
initialized from a different one of the secondary keys; and 

encrypting each sequence of plaintext packets handled between instances of 
ciphertext information loss with a different one of the plurality of second cipher 
streams. 

10. The method as in claim 6 further including the step of repeating the 
steps of claim 5 when each of the generated plurality of secondary keys has been used 
for encryption. 0 

11. An encryption device, comprising: 

a first generator for generating a private key; 

a second'generator initialized with the private key for generating a first cipher 
stream, the first cipher stream partitioned into a plurality of secondary keys; 

an indexer for indexing the plurality of secondary keys; 

means for encrypting plaintext information into ciphertext information using 
the plurality of secondary keys; and 

means for including an index with the ciphertext information identifying which 
of the indexed ^plurality of secondary keys was used in encrypting the plaintext 
information. 

12. The encryption device as in claim 1 1 further including: 
means for exchanging public keys; and 
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wherein the first generator functions to generate the private key from 
processing at least one of the exchanged public keys. 

1 3 . The encryption device as in claim 1 1 wherein the plaintext information 
comprises a plurality of plaintext packets, and wherein the means for encrypting 
comprises: 

a third generator initialized with the secondary keys for generating 
corresponding second cipher streams; and 

means for encrypting each plaintext packet with a different one of the second 
cipher streams. 

1 4. The encryption device as in claim 1 1 wherein the plaintext information 
comprises a plurality of plaintext packets, and wherein the means for encrypting 
comprises: 

a third generator initialized with the secondary keys for generating 
corresponding sefiond cipher streams; and 

means for encrypting each sequence of plaintext packets handled between 
instances of ciphertext information loss with a different one of the second cipher 
streams. 

15. The encryption device as in claim 11 wherein the first generator 
generates a new private key when each of the generated plurality of secondary keys 
from a prior private key has been used for encryption. 

16. A method for encrypting, comprising the steps of: 
generating a private key; 

generating a first cipher stream initialized from the generated private key; 
partitioning the first cipher stream into a plurality of secondary keys; 
indexing4he plurality of secondary keys; 

encrypting plaintext information into ciphertext information using the plurality 
of secondary keys; and 

including with the ciphertext information an index identifying which of the 
indexed plurality of secondary keys was used in encrypting the plaintext information. 

17. The method as in claim 16 further including the steps of: 
exchanging public keys; and 
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generating the private key fiom processing at least one of the exchanged public 

keys. 

1 8 . The method as in claim 1 6 wherein the plaintext information comprises 
a plurality of plaintext packets, and the step of encrypting comprises the steps of: 

5 generating second cipher streams each initialized from a different one of the 

plurality of secondary keys; and 

encrypting each plaintext packet with a different one of the second cipher 
streams. 

1 9 . The method as in claim 1 6 wherein the plaintext information comprises 
10 a plurality of plaintext packets, and the step of encrypting comprises the steps of: 

generating second cipher streams each initialized from a different one of the 
plurality of secondary keys; and 

encrypting each sequence of plaintext packets handled between instances of 
ciphertext information loss with a different one of the second cipher streams. 

15 20. The method as in claim 16 further including the step of repeating the 

steps of claim 13 when each of the generated plurality of secondary keys has been used 
for encryption. 
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